1. Technical Field
This invention relates to the field of telecommunications, and more particularly, to generic service components for wireless services for use with a service logic execution environment.
2. Description of the Related Art
The development of the open network application programming interface (API) represents an important departure from traditional methods for opening the architecture of the public switched telephone network (PSTN). Presently, the Advanced Intelligent Network (AIN) architecture defines a call model which allowes the creation of telecommunications service applications outside of the switch environment. Telecommunications service applications are a la carte telecommunications applications which can perform enhanced services for a telecommunications session established among two or more parties. Exemplary service applications can include Call Waiting, Caller ID, Call Forwarding, Voice Activated Dialing, and Meet-me Conferencing.
When AIN first had been introduced, in terms of the service application creation process, the AIN architecture represented an important advance. AIN separated service development from switching, allowing service logic components to be developed more quickly and placed in specialized network elements attached to databases. Switches, in turn, being free from all service logic, could be optimized for speed and efficiency. Still, typical service applications developed to the AIN specification are written in specialized languages by specially trained programmers using specialized service creation environments.
Importantly, future telecommunications networks will be characterized by new and evolving network architectures where packet-switched, circuit-switched, and wireless networks are integrated to offer subscribers an array of innovative multimedia, multiparty applications. Equally important, it is expected that the process by which telecommunications applications are developed will change, and will no longer solely be the domain of the telecommunications network or service application provider. In fact, in order to provide a broad portfolio of novel, compelling applications rapidly, service application providers will increasingly turn to third-party applications developers and software vendors. Thus, application development in the telecommunications domain will become more similar to that in software and information technology in general, with customers reaping the benefits of increased competition, reduced time to market, and the rapid leveraging of new technology as it is developed.
To make this vision a reality, the principles of AIN have been discarded in favor of a new service application component development paradigm. Specifically, it has been recognized that future integrated networks must offer application developers a set of standard, open APIs so that applications written for compatibility with one vendor""s system can execute in the system of another vendor. In consequence, the cost of applications development can be amortized, reducing the final cost to the customer. Java APIs for Integrated Networks (JAIN) fulfills the requirements of the new service application component development paradigm. Presently, JAIN includes standard, open published Java APIs for next-generation systems consisting of integrated Internet Protocol (IP) or asynchronous transport mode (ATM) networks, PSTN, and wireless networks. The JAIN APIs include interfaces at the protocol level, for different protocols such as Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), and Transactional Capabilities Application Part (TCAP), as well as protocols residing in the higher layers of the telecommunications protocol stack.
JAIN includes a set of integrated network APIs for the Java platform and an environment to build and integrate JAIN components into services or applications that work across PSTN, packet and wireless networks. The JAIN approach integrates wireline, wireless, and packet-based networks by separating service-based logic from network-based logic. FIG. 1 illustrates a conventional JAIN implementation. As shown in FIG. 1, a conventional JAIN implementation can include a protocol layer 102 which can include interfaces to IP, wireline and wireless signaling protocols. These protocols can include TCAP, ISUP, INAP, MAP, SIP, MGCP, and H.323. The JAIN implementation also can include a signaling layer 103 which can include interfaces to provide connectivity management and call control. The conventional JAIN implementation also can include an application layer 104 for handling secure network access and other external services. Finally, the conventional JAIN implementation can include a service layer 106 which can include a service creation and carrier grade service logic execution environment (SLEE) 108.
In JAIN, the protocol layer 102 and the signaling layer 103 are based upon a Java standardization of specific signaling protocols and provide standardized protocol interfaces in an object model. Additionally, applications and protocol stacks can be interchanged, all the while providing a high degree of portability to the applications in the application layer using protocol stacks from different sources. By comparison, the application layer 104 provides a single call model across all supported protocols in the protocol layer 102. Fundamentally, the application layer 104 provides a single state machine for multiparty, multimedia, and multiprotocol sessions for service components in the application layer 104. This state machine is accessible by trusted applications that execute in the application layer 104 through a call control API.
Notably, applications or services executing at the service level 102 can communicate directly with protocol adapters in the SLEE 108. Protocol adapters typically are class methods, callbacks, event or interfaces that encapsulate the underlying resources such as TCAP, MGCP, etc. The underlying resources can be implemented in many programming languages, but a JAIN-conformant protocol product must provide at least the relevant JAIN API. In contrast, an external application or service executing in the application layer 104 does not have to be aware of the underlying resources and can remain oblivious to the fact that some of its session or call legs may be using different protocols.
Service components 112 are the core JAIN components and can execute in the SLEE 108. More particularly, service components 112 are constructed according to a standard component model and, instantiations of component assemblies can execute in coordination with the SLEE 108. Using information regarding the protocol layer 102 which can be incorporated into the SLEE 108, service components 112 can interact with the underlying protocol stacks without having specific knowledge of the protocol stack. Thus, service components 112 can use the call model provided by the signaling layer to implement telephony services. More importantly, the SLEE 108 can relieve the service components 112 of conventional lifecycle responsibilities by providing portable support for transactions, persistence, load balancing, security, and object and connection instance pooling. In this way, the service components 112 can focus on providing telephony services.
Despite the advantages provided by JAIN, however, the development of a wireless service application still requires knowledge of many disparate communications interfaces and protocols for accessing wireless services. For example, presently, a variety of disparate communications protocols exist which support the use of the wireless network. These protocols can include Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Universal Mobile Telecommunications System (UTMS), Wireless Application Protocol (WAP), Mobile Access Protocol (MAP), and i-Mode. In order to develop a wireless service application, a developer must be familiar with the particular wireless protocol interface corresponding to the wireless service or function being incorporated into the wireless service application being developed. For example, WAP is a specification for a set of communication protocols which standardizes wireless device communications. Thus, one developing a service application for wireless services for handheld devices would need at least a general familiarity with WAP to successfully develop such a service application. Similarly, a service application developer desiring to provide an application service providing interactive use of a web site through a wireless handheld device likely would need to be familiar with GPRS which can provide a higher data rate than WAP.
Solutions such as GPRS and WAP can facilitate the interoperability of various devices and services, as well as minimize the use of proprietary solutions. Still, to develop a variety of wireless service applications, a developer must be familiar with an assortment of wireless protocols and interfaces. Accordingly, the number persons having the necessary expertise in using different wireless communications protocols and interfaces can be limited. Typically, the knowledge required to implement a wireless application using a particular protocol can be so highly specialized that only one person may have the necessary expertise within a given organization. This personnel dilemma often means that each time a solution is developed for one particular wireless format, the solution is not easily ported over to a different wireless format or protocol. Moreover, because programming expertise can be so highly specialized, porting a service application to another format or protocol typically requires additional personnel possessing expertise within the target format or protocol.
In sum, the highly specialized nature of wireless service application development can result in increased developmental expenses and longer design cycles. Further, the complexities involved make recycling of systems, features, and applications extremely difficult.
The invention disclosed herein concerns a method and a system for providing a generic service component (GSC) for accessing wireless service applications for use with a service logic execution environment (SLEE). In particular, a GSC can provide a common application programming interface (API) for accessing a particular wireless service application. Correspondingly, each GSC can include the necessary functionality and protocol information for interacting with those wireless service applications. The GSC can hide protocol specific and interface specific details from the developer allowing the wireless service application to be accessed via the common API provided by the GSC. Accordingly, each GSC can be specifically suited to interact with the interface of a particular wireless service application while providing a common API to other GSCs and service applications executing within the SLEE. In this manner, the protocol and interface information specific to each wireless service application can be contained within a corresponding GSC.
One aspect of the invention can include an advanced intelligent network for use with a wireless service. The invention can include a SLEE, at least one service application executing in the SLEE, and at least one GSC for use with a wireless service application communicatively linked to the service application. The GSC can include an interface to the wireless service application which is external to the SLEE.
A second aspect of the invention can include a GSC for use in a telephony environment having a SLEE. The GSC can be registered with the SLEE and can interact with a wireless service application which can be external or internal to the SLEE. At least one client service instance can be included in the GSC where each client service instance can correspond to a wireless service application. Additionally, each client service instance can include a content interface for publishing an interface to the client service instance.
The GSC can include a service wrapper. The service wrapper can provide a common interface to at least one of the client service instances for routing events between the SLEE and the at least one client service instance. The service wrapper can include a deployment descriptor for providing configuration information to the SLEE and a service interface for publishing an interface to the service wrapper. Also, the service wrapper can include a protocol stack for managing communications in a telephony environment. Notably, the GSC can interact with other GSCs, external applications, service components, or protocol stacks.
Another aspect of the invention can include a method of routing events between the SLEE and a GSC for use with a wireless service application in a telephony environment. In that case, the method can include the GSC registering with the SLEE and the GSC receiving a first event routed by the SLEE. The first event can correspond to a wireless service application which the GSC has registered to receive from the SLEE. Further the first event can be from a protocol stack, a service component, an external application, or another GSC. At least one client service instance can be instantiated for communicating with a wireless service application. The client service instance can interact with the wireless service application. A second event can be posted to the SLEE responsive to the interaction between the client service instance and the wireless service application. The second event can correspond to the interaction.
The method of the invention can be implemented in a machine readable storage, having stored thereon a computer program for routing events between a SLEE and a GSC in a telephony environment. Accordingly, the computer program can have a plurality of code sections executable by a machine for causing the machine to perform the steps of causing a GSC for use with a wireless service application to register with a SLEE and the GSC receiving a first event routed by the SLEE. The first event can correspond to a wireless service application which the GSC has been registered to receive from the SLEE. Notably, the first event can be from a protocol stack, a service component, an external application, or another GSC. The machine readable storage further can cause at least one client service instance for communicating with a wireless service application to be instantiated. The client service instance can interact with the wireless service application. Also, a second event can be posted to the SLEE responsive to the interaction between the client service instance and the wireless service application. The second event can correspond to the interaction.